Collection of Internet/Collection of Internet.iso/infosrvr/dev/www_talk.930/[e-mail] _Fri May 14 21:52:54 1993.msg

Internet Message Format | 1994-01-24 | 4KB

Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA21094; Fri, 14 May 93 21:52:54 MET DST
Received: from HAL.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
    id AA18319; Fri, 14 May 1993 22:13:52 +0200
Received: from hysteria.hal.com by hal.com (4.1/SMI-4.1.1)
    id AA18095; Fri, 14 May 93 13:13:39 PDT
Received: by hysteria.hal.com (4.1/SMI-4.1.2)
    id AA18914; Fri, 14 May 93 15:13:37 CDT
Date: Fri, 14 May 93 15:13:37 CDT
From: [e-mail] (Dave Brennan)
Message-Id: <[e-mail]>
To: [e-mail] (Daniel Miles Kehoe)
Cc: Dave_Raggett <[e-mail]>, [e-mail]
Subject: Re: HTML+ and books
In-Reply-To: <[e-mail]>
References: <[e-mail]>

On the issue of automatically generating a TOC, I don't think it would be
very easy to generate a coherent book TOC, even given a set of nodes to uses
as a basis.  You'd have the headings, but how would you order them?  I
suppose a program could try and decide upon some kind of structure/ordering
from the links in the nodes, but it wouldn't be easy.  The best use of some
kind of automated TOC generator might just be to give a human somewhere to
start from.  In a program like Frame, the task is a lot easier because you
are already starting with a limited set of information that has a linear
ordering and (supposedly) meaningful elements from which to generated the
TOC.

I don't see books as something that the user can just conjure when he or she
is trying to track down some information.  There's better ways to handle
that kind of interaction requirement.  I see books as something that are
authored by someone, much like a node is written.  The cool thing about this
is that this would make it possible for people to easily write "virtual
books" based on existing information.  Of course, they may wish to add some
nodes of their own while they're at it to tie everything together.  But the
large existing base of information is going to make organizing and finding
information easier than ever.

> It's interesting to consider that printing a book and searching the Web
> might be closely related issues.

It sure is!  The interesting part is that the same basic organizational
information can be used in both cases.

> I've come to believe that a book is not a document, but rather a point
> of access to an organized collection of documents.

Exactly my point.  In a meta-sense, though, even a book is a document,
albeit at a higher level of abstraction.  Carrying this one step further,
who's to say I can't put together a "library" that contains bunch of books.
I still like to picture it as "views" on the information.  You've got access
to a giant collection of (mostly) unstructured information, and by looking
at it through one or more views the information can become much more useful.

> From this point of view, it seems a bad idea to include "structuring
> elements" inside documents that tie them together for printing (if that's
> what you were suggesting), though there's no harm in encouraging authors
> to provide one or more T.O.C.'s (or encouraging readers to contribute
> their own T.O.C.'s).

Yes, that's just what I was suggesting.  Although it is more convenient
to have that information available, I'm afraid of the limitations that
it implies.  And if you can't already guess, I'd be all for encouraging
anyone and everyone to contribute their own TOCs.

--
Dave Brennan                                      HaL Computer Systems
[e-mail]                                         [phone]